Typically a communication system comprises a network entity which provides services and terminals which use the services. In some communication systems, the server may be part of the network and in some communication systems, the server may be a separate entity. The network entity and the server are collectively referred herein as server and the terminals are referred herein as clients or client terminals. In the present disclosure, the terms clients and client terminals are used interchangeably and the terms server, network and network entity are used interchangeably. The communication path between a server and the client is referred herein as a “connection.” Typically in a communication system the communication path from the server to the client terminal is herein referred to as a downlink (DL) or downlink channel, and the communication path from the client terminal to the server is herein referred to as an uplink (UL) or uplink channel. The data transmitted by the server to the client terminal on the downlink channel is herein referred to as downlink data transfer and the data transmitted by the client terminal to the server on the uplink channel is herein referred to as uplink data transfer.
Some communication systems are wire-line and some others are wireless. Communication systems based on Digital Subscriber Line (DSL), Cable Modem, fiber optics are examples of wire-line communication systems. Communication systems based on IEEE 802.16e standard, IEEE 802.11 standard, 3rd Generation Partnership Project (3GPP) Wideband Code Division Multiple Access (WCDMA) standard, or Long Term Evolution (LTE) standard are examples of wireless communication systems. In wireless communication systems, a client terminal may also be referred as mobile station (MS).
Normally applications may use the connection established by the communication system between the server and the client to transfer user payload data. For example, internet browsing and Voice over Internet Protocol (VoIP) are some of the applications which may use a communication system to communicate between the server and the client.
Typically some applications may involve bidirectional data transfer. In such applications the bidirectional data transfer may be between a client terminal and a server as shown in FIG. 1, or the bidirectional data transfer may be between two client terminals as shown in FIG. 2A and in FIG. 2B. In some communication systems, an instance of the application may be running in the server and it may coordinate with the instances of the application running in one or more client terminals as shown in FIG. 2A for the transfer of user payload data between the client terminals. In some communication systems, the server may act as a communication path between client terminals and the instances of the application may run only in the client terminals as shown in FIG. 2B.
Normally, the air interface between the network and the client terminal may be organized in terms of frames and it normally spans a predefined duration. The frame duration may be different for different communication systems and it may be normally on the order of few milliseconds. For example, the frame duration may be 5 milliseconds.
Typically, in wireless communication systems the client terminals are mostly handheld portable battery operated devices. Hence it is important for the client terminals to operate in a power efficient manner. To reduce power consumption, the client terminal may turn off some or most of its hardware and software components when there is no data transfer expected in uplink, or in downlink, or in both uplink and downlink. The state in which the client terminal turns off most of its hardware and software components is referred to herein as “sleep state” (SS). The state in which the client terminal is involved in uplink data transfer or downlink data transfer or both uplink data transfer and downlink data transfer is referred to herein as “active state” (AS). To reduce power consumption in the client terminal, it is desirable to operate the client terminal in the sleep state as much as possible while performing data transfer required by the application.
The transition from sleep state to active state of the client terminal is referred to herein as “wake-up” state. The transition from active state to sleep state of the client terminal is referred to herein as “entering-sleep” state. The client terminal may transition from sleep state to active state for either uplink data transfer or downlink data transfer or both uplink data transfer and downlink data transfer. Some hardware and software components may be specific to uplink or downlink and they may be independently turned on or turned off based on uplink or downlink data transfer. Some hardware and software components in the client terminal may be common for both uplink data transfer and downlink data transfer and may have to be turned on for either uplink data transfer or downlink data transfer.
The wake-up state and the entering-sleep state may have the overhead in power consumption. Normally the power consumption may be higher during both the wake-up state and the entering-sleep state when compared to that of the sleep state but may be lower when compared to that of the active state. Typically the transition time for the wake-up state is longer than the transition time for the entering-sleep state. Also in general the power consumption during the wake-up state may be higher than that of during the entering-sleep state. An example of sleep state to wake-up state then to active state then to entering-sleep state and then back to sleep state transitions in a battery operated client terminal is illustrated in FIG. 3. As and when appropriate, the client terminal may enter into sleep state and active state and an example is illustrated in FIG. 4. For the rest of the discussion, the wake-up state and the entering-sleep state may not be explicitly discussed or shown in the drawings but they are always present.
Typically in most applications, the uplink data transfer and/or the downlink data transfer may not be continuous. For example in voice applications, the user's voice may be digitized, buffered, processed and then transferred as user payload data. Normally the user payload data may be transferred in bursts and in some cases they may be transferred in periodic intervals. FIG. 5 illustrates an example where the user data is sampled at every Ts milliseconds and the sampled user data may be buffered and packetized as user payload data every Tp milliseconds for transmission. This process is herein referred as “payload processing.”
Normally in some applications, the client terminal may send the uplink data and may receive the downlink data at periodic intervals and may be at different instances as shown in FIG. 6A and FIG. 6B. In some applications the time interval between two consecutive uplink data transfer and the time interval between two consecutive downlink data transfer may be the same and an example of such application may be VoIP. To support such applications, the client terminal may enter into active state for the uplink data transfer and for the downlink data transfer separately as shown in FIG. 6C. This may lead to increased power consumption at the client terminal and this may be a significant disadvantage for a battery operated client terminal. In some applications the time interval between two consecutive uplink data transfer and the time interval between two consecutive downlink data transfer may be different and an example of such application may be internet browsing.
In some applications the client terminal may send the uplink data in non-periodic intervals and may receive the downlink data in non-periodic intervals. The uplink data transmission and downlink data reception may be at different time instances as shown in FIG. 7A and FIG. 7B. To support such applications, the client terminal may enter into active state for the uplink data transfer and for the downlink data transfer separately as shown in FIG. 7C. This may lead to increased power consumption at the client terminal and this may be a significant disadvantage for a battery operated client terminal.
Typically for a bidirectional data transfer applications, the same type of applications or different types of applications may be running in two different entities. For example, one instance of an application may be running in a client terminal and another instance of an application may be running in a server or in another client terminal. The application entity which sends the payload data is referred herein as “source application entity” and the application entity which receives the payload data is herein referred as “destination application entity.”
The peer to peer communication between two application instances running in the source application entity and the destination application entity may be viewed as a virtual connection and the connection is herein referred to as “logical connection” as illustrated in FIG. 2A and FIG. 2B. Typically the source application entity and the destination application entity may exchange some of the connection information and/or the Quality of Service (QoS) information when they establish the application connection. Normally the applications running in source application entity and destination application entity may exchange additional information along with the user payload data for better quality of service. The additional information exchanged between two application entities may include but not be limited to source application entity identifier, destination application entity identifier, user payload data length, user payload data packet number, payload data time stamp, etc. The information that may be exchanged in addition to the user payload data is herein referred to as “control information.” Some applications may send the control information along with the user payload data as a predefined header as shown in FIG. 8. Such header is herein referred as “payload header.” For example, in Real time Transport Protocol (RTP), a commonly used protocol in bidirectional real time applications, some payload header information includes source application entity identifier and payload data time stamp. Some applications may send the control information as a separate control payload data and such control payload data is herein referred to as a “control message.” The user payload data time stamp in the control information (inside a payload header or inside a control message) indicates the time at which the source application entity sends the user payload data to the destination application entity. The payload data time stamp sent by the source application entity in the payload data may help the destination application entity to know the time at which the payload data was sent by the source application entity.
In wireless communication systems, applications using conventional methods for bidirectional data transfer may exchange the data at different instances and may provide acceptable level of performance but at higher power consumption.